[译文] i386和x86_64: 破镜重圆？

原文：http://lwn.net/Articles/243704/
原作者：Jonathan Corbet
原作时间：July 31, 2007
译者：王旭 | gnawux(at)gmail.com |
翻译时间：2007年12月6日

译者注：题目叫破镜重圆当然不好了，有点辞不达意，不过，为了吸引眼球，损点人品也就认了。

译者又注：这次是正经话了，这两个架构即将在2.6.24中合并，于是译者才考古出来翻译的。好了，后面是译文了，译者不注了。

kernel 源码目录中的 arch 目录存放着所有架构相关的代码。尽管开发社区在过去多年以来都在致力于让代码尽可能地通用化，这个目录依然十分庞大。Linux目前支持26个不同架构，其中很多又有一些子架构。这26个架构中有两个分别是 i386 (Linux 最初支持的架构) 和 x86_64 —— i386 的大哥。这两种架构之间有太多共性了，而也确实已经有一些工作正致力于在这两个架构间尽量地共享代码。尽管如此，这两种架构的源码树仍然是彼此天各一方的。

至少在一些开发者眼里，这两个架构的彼此孤立是个问题。对于一个架构的 bug fix 常常对另一个也是可用的，但是不是都应该施加于两个地方就不清楚了。对于新功能也需要加两次。在这些情况下，一个架构的代码更改，常常破坏另一个架构。这样，负责架构相关项目的开发者们——譬如常常提到的虚拟化团队——不得不疲于同步两个强烈相关的源码树。与之相对应，32位和64位的 PowerPC 架构已经在 2.6.15 的内核中合并为了一个架构源码树，并且大家一致认为这十个成功的合并。不过，类似的合并还没有发生在 x86 的变种们之上。

这种情况可能很快得到改变：Thomas Gleixner 和 Ingo Molnar 最近发起了一个关于合并两个架构的补丁的动议来征求广大开发者的意见。这个补丁将十分巨大，超过9MB 涉及 1764 个文件。它非常依赖于内核源码树的当前状态，因为它只能施加于源码 git 仓库的某一特定时刻 (commit point)。这还不是将要被采纳的补丁，它的目的在于演示打过补丁之后源码树将是什么样子。如果真的到了合并这个补丁的时候，将会是另一番情景：

我们的下一步计划是生成一个细粒度、可拆分的，完全可用的替换，以将当前代码更新到新的 x86 源码树。它将呈现为 1000-2000个 commit (译注：git的版本控制单位，大致相当于分成1000-2000个补丁，打在源码包上。)

这也的确有一些危险。正是了解这些危险，补丁的开发者们努力地让这些补丁的过程更加可靠。这次合并将不会带来任何二进制代码变化：源码树在变更前后将可以生成完全相同的内核映像。

这个补丁创建了一个新的称为 x86 的架构，并将两个已有架构的所有内容移动到其中。有些地方每个架构都有相同文件的完全一样的靠北，只要在新架构源码树中保留一份即可。而更多的情况下，两个架构在同样的位置有内容不同的同名文件，在此情况下，两个文件将被移动到新的源码树中，并相应给与 _32 或 _64 的后缀。这样，比如两个架构都包含 kernel/ioport.c，那么在新的 x86 架构中就同时拥有 ioport_32.c 和 ioport_64.c 了。补丁中还用了一些简单的手法，以保证为目标架构编译代码会生使用确的文件。

在很多情况下（如果不是大部分情况的话），两个文件都有大量的公共代码，兵器，公共代码就留在那了。这个补丁的出发点是：目前的阶段的任务是让两个架构的源码树合并而不影响生成内核映像，这恐怕是这么一个大改动能够被进一步推进的唯一途径。一旦这些内容被合并了，在个体文件中排除重复代码的机会也就出现了——需要被处理的文件通常紧挨着。可以想象一个代码清理大军就将扑向这个工作，各自为战地解决这些问题了。当这些问题也被解决了的时候，我们就有了一个漂亮的、挤出所有重复代码的 x86 架构了，大家就都会高兴了。

不过也未必， Andi Kleen表达了他对于这个改动的反对意见：

我觉得这不是个好主意，因为这意味着我们将永远不会丢掉那些老垃圾。IMNSHO (译注：in my not so humble opinion, 源于 IMHO——in my humble opinion，以我愚见，这里表示发文者还是很自信的)，arch/x86_64比 arch/i386 在很多方面简洁多了，我更倾向于保存 x86_64 。同样，总的说 arch/x86_64也比 arch/i386 更容易hack，因为它更容易回退测试并且在测试时需要考虑较少的无用数据。我觉得完全去掉老旧的东西之外，没有办法在i386中解决这些问题。

Andi 作为 i386 和 x86_64 架构的维护者在这个讨论中非常强势。他的核心论点是——分成两个架构可以将很多老旧的问题封闭在 i386 源码树中，这是内核代码管理的一个基本思路。只支持较新硬件的代码往往比同时也处理老旧硬件的代码要干净很多，不过，去掉仍在使用中的硬件的支持是很难被接受的。所以，新的子系统被作为新的代码部分增加进来，而老的代码可以被分离出来用于支持老硬件直到它们随风而逝。这方面一个经典的例子是SATA的支持是通过一个新的子系统而不是IDE的扩展来实现的。Andi 和其他一些开发者认为 x86系列处理器也应该这样处理。

不过大多数 讨论的参与者都不同意Andi的意见。和老IDE设备不同，32位架构短时间内不会消失。而i386的变种数量也非常至少。Linus 表示，带着老代码继续前进的时候，把它作为一个共享代码树的一部分比扔进一个角落里要好。最终，争论的结果就是依照最初的提议，基本上公认一个统一的源码树是正确的解决方案。

有一些建议认为这些补丁应该直接进入 2.6.23 内核，不过有可能不这么干。2.6.23 已经有很多新东西了，并且这个补丁也太新了。同时，我们还没有将这个补丁拆成上千个 commit 呢。

更多个关于这个问题：关于合并的讨论还没有完成。在维护者不同意的情况下将两个架构重写为一个是种非常特别的敌意的接管行为。维护者对补丁没有绝对的否决权，但是在一个这么大的补丁的问题上否决维护者的一员不是一件小事。所以，统一 x86 架构的开发者们仍然面临着一个巨大的挑战：他们必须在漂亮地解决技术问题的同时说服大部分的开发者，使他们认为这个改动是必要的。所有牵扯进来的人都非常关心是否可以找到一个方法来说服与他们相关代码的维护者。